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METHOD FOR LOADING APPLICATIONS IN A MULTIAPPLICATION 
ONPLATFORM SYSTEM EQUIPPED WITH DATA PROCESSING RESOURCES, 
CORRESPONDING EXECUTING SYSTEM AND METHOD 

5 The present invention concerns a method for loading applications into a multi- 

appiication embedded system equipped with data processing resources, the corresponding 
embedded system, and the method for executing an application of a corresponding embedded 
system. 

The present invention more specifically concerns the creation of a firewall between 
1 0 modules sharing the same memory space in systems embedded in multi-application portable 
objects using an intermediate pseudocode and an associated virtual machine. 

The "Java" (registered trademark) technology introduced by Sun is based on an 
Lp object-oriented programming language, '*Java," and an associated virtual machine. This 
ffi technology was developed on stations or PCs, hereinafter referred to as conventional Java 
'^:15 platforms, having high CPU power and a large memory on the order of 1 megabyte. 

For several years, the concepts of Java technology have been adopted and adapted to 
" run on embedded systems in portable objects, for example in the format of a credit card or a 

SIM micromodule incorporating a microprocessor and commonly called a smart card, GSM 
(Global System for Mobile Communication) portable telephones, PCMCIA cards or any 
J: 20 other portable terminals. Hereinafter, the term card will be used to designate any of these 
portable objects. The programming of embedded systems, heretofore performed in an 
assembly language, is now possible in an advanced language like Java, making it possible to 
accelerate the development of client applications. 

This new type of platform specific to the embedded systems of a portable object, 
25 hereinafter called a specific platform, constitutes a subsystem of the conventional platform. 
The differences result from the smaller environment of embedded systems. Conventionally, 
as represented in Fig. 4a, a smart card (10) comprises an input-output system (11) linked to 
the microprocessor (14), a volatile RAM (Random Access Memory) (12), a nonvolatile 
memory constituted by a ROM (Read-Only Memory) and a programmable nonvolatile 
30 memory (15) constituted by a flash RAM or EEPROM (Electrically Erasable Programmable 
Read-Only Memory). All of these elements are linked to the microprocessor by a link bus. 
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For example, in the best of cases using the newest currently existing components, a smart 
card comprises a ROM a 32-kilobyte EEPROM, and a 2-kilobyte RAM. 

In a conventional Java system, an application is written on a station or PC. Its source 
code is complied into an intermediate pseudocode called "Java Byte Code" or byte code, 
5 which is independent of the machine code of the platform used. The application is then 

downloaded into the target platform or conventional Java platform. The loaded application, 
constituted by a set of classes called client classes, whose methods have been compiled into 
the pseudocode, is based on application program interfaces or APIs. Application program 
interfaces make it possible to standardize the user interface, to control an editor, a keyboard 
10 or a printer, for example. The virtual machine of a conventional platform comprises a 

pseudocode verifier, a dynamic class loader, a pseudocode interpreter for translation into 
^ machine code, and a security manager. 

lj!; The main difference between a conventional virtual machine and a virtual machine of 

5=' an embedded system, called a specific virtual machine, is due to the fact that the virtual 
^^15 machine of an embedded system is broken down into two separate parts. According to Fig. 
M= 4b, the virtual machine comprises a part (30) outside the specific platform (40), called an 
f ' "off-platform" virtual machine, comprising a converter (32) and a part (41) inside the card 
C= constituting the specific platform (40), called an "on-platform" virtual machine, which 
y. includes the pseudocode interpreter. 

20 Thus, in the case of a specific platform, the source program (21) of the application is 

Ih- written, compiled into intermediate pseudocode by a compiler (22), and verified by an 

intermediate pseudocode verifier (31) in a conventional station (20), then converted by the 
converter (32), located in the same station (20) or in another station. After possibly passing 
through a signer (34), the application is then downloaded into the EEPROM (15) of the 
25 portable object or specific platform (40). This loading is performed by a loader comprising an 
off-platform part called a downloader (33), and an on-platform part called a loader (42). 
Unlike what exists in a conventional platform for a station, the virtual machine (41) of a 
specific platform (40), located in ROM with the operating system (48), cannot include an 
intermediate pseudocode verifier, which is too large to be stored and/or run in the portable 
30 object. Nor does the specific platform (40) contain a dynamic class loader. In fact, for the 

field of application of the invention, in the off-platform virtual machine (30), the verifier (31) 
verifies that the compiled classes are correctly formed, and verifies the language violations 
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specific to the description of the specific platform. The converter (32) does the work required 
to load the classes and resolve the references. The converter handles the static linking of the 
classes, and resolves the symbolic references to the classes, methods and attributes already 
present in the card. It apportions storage and creates the data structures for representing the 
classes, creates the static or native methods and attributes, and initializes the static variables. 

The runtime environment (or RE) of the specific platform comprises the "on- 
platform" virtual machine (41), limited to an interpreter, an API platform, and the associated 
so-called native or static methods (43). The API platform comprises the APIs (Application 
Program Interfaces) (44) defining a set of classes called system classes (45), and the call 
conventions by means of which an application accesses the runtime environment (RE) and 
the static methods (43). The static methods (43) execute the memory allocation, input and 
output, and cryptographic services of the card. 

The interpreter of the "on-platform" virtual machine of the card (41) supports the Java 
language, and reads the intermediate pseudocode sequentially, instruction by instruction. 
Each conventional instruction of this intermediate pseudocode is inteipreted in the language 
of the microprocessor by the interpreter, then executed by the microprocessor. As a general 
rule, the conventional instructions of the intermediate pseudocode make it possible to handle 
advanced functions such as arithmetic processing and object manipulation. The notion of an 
object relates to data processing objects such as lists, data arrays or the like. The so-called 
client classes (46) of the applications and the system classes (45) of the APIs are all loaded 
into the same memory space and are managed by means of a class table (47). 

The virtual machine (41) is also responsible for managing the classes and objects and 
for maintaining the separations or firewalls between the applications so as to allow secure 
sharing of the data, also called attributes, variables or fields. 

In the case of a portable object like a smart card, an application of a specific platform 
can be activated directly by the runtime environment (RE) when a selection APDU 
(Application Protocol Data Unit) sent by a service or terminal is received by the card. 

In order to restrict access to the data among the code parts sharing the same memory 
space, one of the conventional methods in a conventional platform is based on an explicit 
restriction of visibility declared in the source code. According to Fig. 4c, the methods (NMl, 
NM2) and (NM3, NM4), respectively, and the attributes (NAl, NA2) and (NA3, NA4), 
respectively, are encapsulated into classes (NCI3) and (NCI2), respectively, which 




themselves belong to packages (Package 1) and (Package n), respectively, each of which 
contains several classes. A class can be public, like (NCIl or NCI2), or private, like (NCI3), 
in relation to a package, which in the latter case implies that only the classes of the same 
package can access this class. The methods (for example NM2) and the data (for example 
5 NAl) of one class (NCI3) can be private in relation to the class (NMl, NAl), which is itself 
private in relation to the package (Package 1), or public in relation to the package (for 
example NMl, NA2). This restriction of visibility makes it possible to obtain flexible access 
among the various sets of packages (Package 1 , Package n) stored in the same name space, 
but it has several disadvantages. The conventional or specific platform does not support the 
10 notion of sub-packaging well. The client classes of an application of large size must be 
distributed among various sub-packages, which represent different packages only for the 
virtual machine. In order for these resources to be shared among these sub-packages, these 
resources are necessarily declared public, thus rendering them visible to any other package. It 
S^; is thus difficult to clearly organize the packaging of various applications for applications of 
CI 5 large size, and to obtain firewalls between the applications. 

In the case of the conventional platform, in a station, the maintenance of the 
^ ' confidentiality of the resources as declared in the source programs is based on dynamic 
C= verifications. In order to perform these dynamic verifications, the virtual machine must have 
lj. all the information relative to the declarations of the access restrictions for each class, method 
2": 20 or attribute, which is impossible in the case of the memory space available in the on-platform 
M virtual machine using the pre-linked intermediate pseudocode or byte code of the off- 
platform virtual machine. In the case of a specific platform of a portable object, the access 
restrictions can be verified statically during the compilation and can be re-verified by the 
verifier of the off-platform part. It is essentially assumed that what is loaded into the specific 
25 platform of the portable object is correct, since no verification can be performed in the 

specific platform due to the loss of information during the conversion phase. Moreover, there 
is no guarantee that a package cannot be extended or modified by new classes coming from 
alien sources, which can entirely destroy any security based on the utilization of private 
packages. 

30 The second means provided by the virtual machine of a conventional platform is the 

notion of name space separation. With the dynamic linking schema of a conventional 
platform, the classes can be loaded from directories of the local file system called 
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"ClassPath," previously declared as constituting the location of the system classes forming 
the conventional API platform, or from other directories of the local file system or from 
remote servers. The client classes of an application, outside the "ClassPath," must be loaded 
by a specifically programmed class loader. This characteristic is used particularly for loading 
5 Java applications via authorized Java browsers. Thus, applications coming from different 
sources are loaded by different class loaders. For each locator, commonly called a URL 
(Uniform Resource Locator), a specific instance of a class "application class loader" is used. 
The external name of a class is the assembly <Name Of Package> -h <Name of Class>. When 
a class is loaded, it is stored in an internal class table, and a reference related to the class 
10 loader used to load this class is added into a prefix of the name of the package of the class. 
The name of the class is therefore «Reference of Class Loader> + <Name of Package> + 
<Name Of Class». Thus, classes declared as belonging to the same package but loaded by 
51 different class loaders are not perceived by the virtual machine as belonging to the same 
package. 

i'aS During the resolution of a reference, the usual policy of class loaders is to first search 

y* in the system classes, and in case of failure, to search through the class files present at the 
^ ^ location vc^here the loader can load the classes. According to this operating principle of the 
a loader, an application cannot directly access the client classes of another application loaded 

by a different class loader. An application can access all the public resources of the public 
^:;^20 classes of the ClassPath, but the classes of the ClassPath cannot directly access the classes of 
1=4= an application, although they can refer to instances of client classes of the application by 

converting them into a public type defined in the ClassPath. An application cannot extend or 
modify packages of system classes of the ClassPath or of any other applications loaded by 
different class loaders. Using name space separation by inserting a reference of the class 
25 loader into the name of the class, in addition to the complete typing provided by the Java 
language, makes it possible to provide an effective firewall between the applications. The 
innate name space separation mechanism makes it easy to load new applications. The 
applications can exchange objects by interjecting classes specifically programmed for this 
purpose and located in the "ClassPath." An application can use an object coming from 
30 another application loaded by a different class loader if this object can be changed into a 
public type defined in the "ClassPath." 
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♦ * 

Unfortunately, this name separation mechanism, based on a conventional virtual 
machine and its dynamic linking process, cannot be implemented in a specific platform. The 
dynamic linking cannot performed by the virtual machine of a specific platform, since it 
requires a memory space that allows the storage of a class file of a conventional Java 
5 platform having unresolved references. In a specific platform, the system classes of the APIs 
and the client classes of the applications are not isolated in particular naming spaces. 

The object of the present invention is to offer a solution that provides the advantages 
of name separation in the context of embedded systems having a two-part virtual machine, 
the static linking schema being implemented by the off-platform part. 
10 In the context of multi-application embedded systems, such as for example payment 

terminals, it is necessary to have high-performance firewalls between Java applications 
furnished by different sources, such as different payment systems (Visa, MasterCard, etc.). It 
can be useful to allow flexible cooperation between applications coming from different 
sources. The embedded system should also be easy to update by downloading new 
5 applications or new utility modules, or upgrades, without disturbing the applications already 
loaded. 

A first object of the invention is to offer a loading method that makes it possible to 
obtain robust firewalls between the applications, while allowing cooperation between the 
applications and making it possible to upgrade the applications or to load other applications. 
0 This object is achieved through the fact that the method for loading applications into 

an embedded system according to the invention, comprising a runtime environment including 
a virtual machine comprising an intermediate pseudocode language interpreter and 
application programming interfaces (API), from a station on which the source code of the 
application is written, compiled into pseudocode by a compiler, verified by a verifier, 

25 converted by a converter and loaded by a loader, is characterized in that: 

- the conversion comprises the performance of the static linking of a plurality of sets 
of packages to be stored in the same name space in the embedded system, called modules, by 
assigning an identifier to each module (MID), and a reference number to each class, each 
method and each attribute encapsulated in the classes of the module, 

30 - the reference to a method or an attribute in the linked pseudocode of a module,, 

being coded in three bytes constituted by an indicator indicating the reference to a class 



6 



internal or external to the module, the number of the class, and either the number of the 
method or the number of the attribute, 

- the modules loaded are one or more application program interface modules, called 
API modules, comprising system classes or service modules, each corresponding to an 
5 application, a reference to an external class being systematically interpreted by the virtual 
machine as a reference to an application program interface module. 

According to another characteristic, the loading of the modules into the embedded 
system comprises the storage of at least one array representing the modules, the number 
between 0 and n associated by the linker with a module constituting the index of said module 
10 in the array, and a table storing the association of the index in the array representing the 

identifier (MID) of said module, said array and the table being in programmable nonvolatile 
memory, an external reference to an external module in the pseudocode being interpreted by 
^ ; the interpreter of the virtual machine as constituting an index for access to the module 
Si equivalent to the one in the module array. 

Si 5 According to another characteristic, the loading comprises the storage, for each 

J module, of an array representing its classes, comprising a reference to the index of its module 

ff' and, for each class, an array representing attributes and methods. 

U According to another characteristic, the modules are referenced in a single module 

array, the system classes are contained in a single API module, and any reference to an 
SI20 external class in the pseudocode different from n will be interpreted by the virtual machine as 
n. a reference to said API module. 

According to another characteristic, the classes being declared public, or in private 
packages, the attributes and methods being declared protected, in private packages or in 
private classes, the numbering of the classes is done in order of the public classes followed by 
25 the classes in private packages; the numbering of the attributes or methods is done by the 

converter in order of the attributes or methods that are public, protected, in private packages, 

and in private classes. 

According to another characteristic, the system classes are contained in several API 
modules that can be loaded separately, the loader maintains in the programmable nonvolatile 
30 memory two arrays representing modules and two corresponding MID/IMi association tables, 
one for the API modules and the other for the non-API modules, the loader loading the 
modules into one of the two arrays based on the nature of the module specified in its header. 
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any external reference of a module of the module array being interpreted as a reference to the 
index of the API module. 

According to another characteristic, the static linking of a module is performed in 
such a way that the reference to a class external to a non-API module in the intermediate 
pseudocode is an index in an array of the header of the module, wherein each entry is an 
identifier (MID) of a referenced API module, the loading of said module into the target 
platform comprising the replacement of said reference with the number of the index of the 
API module obtained from the identifier (MID) in the MID/EVIi association table of the API 
modules. 

Another object of the invention is to offer a corresponding embedded system. 

This object is achieved through the fact that the embedded system according to the 
invention, comprising a virtual machine and an API platform including application program 
interfaces, a fixed nonvolatile memory, a programmable or modifiable nonvolatile memory, 
and a random access memory, is characterized in that the programmable nonvolatile memory 
comprises at least one API module comprising system classes and service modules, at least 
one array representing modules, in which the modules are indexed, and a table associating the 
index of a module in the representing array with the identifier of said module, each module 
comprising an array representing classes, in which the classes are indexed and in which each 
class has a reference to the index of its module, each class comprising an array representing 
attributes and methods, in which the attributes and methods are indexed, the reference to a 
method or an attribute being coded in at least three bytes corresponding to a reference to a 
class internal or external to the module, a reference external to the module constituting the 
index of the API module in the module array, a class number coiresponding to the index of 
the class in the table representing the classes of the module, and a method or attribute number 
corresponding to the index or the method or the attribute in the array representing the 
methods or attributes of the class of the module. 

According to another characteristic, the embedded system includes means for 
comparing the first byte of the three bytes encoding a reference to a method or an attribute to 
a given value n in order to decide whether it is an internal or an external class. 

According to another characteristic, the embedded system comprises a main module 
comprising the main program of the system. 
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According to another characteristic, the classes are indexed in order of the public 
classes, followed by the classes in private packages, and the attributes and methods are 
indexed in order of the attributes or methods that are public, protected, in private packages, 
and in private classes. 

5 According to another characteristic, the programmable nonvolatile memory comprises 

several API modules comprising system classes, two arrays representing modules, one for the 
API modules and the other for the non-API modules and the main module, and two MID/IMi 
association tables, each corresponding to an array representing modules. 

According to another characteristic, the embedded system comprises an access 
10 manager class ''Access Manager" of an API module comprising a method that makes it 

possible to create an instance of a service module, via the main module, said class having a 
protection that prohibits it from having more than one instance. 
^; Another object of the invention is to offer a method for executing an application 

tti present in a multi-application embedded system. 

This object is achieved through the fact that the method for executing an application 
f: of a multi-application embedded system, comprising a runtime environment including a 
ff=' virtual machine comprising an intermediate pseudocode language interpreter and application 
n programming interfaces (API), is characterized in that during the execution of the 
^'"^ intermediate pseudocode of a service module, corresponding to an application, referenced in 
Si20 a module array, the reference to a method or an attribute in the pseudocode, coded in at least 
J^;^ three bytes corresponding to a reference to a class internal or external to the module, a class 

number and a method or attribute number, a reference external to the module is interpr-eted by 
the virtual machine as a reference to the index of an API module in the array of the API 
module or modules. 

25 According to another characteristic, upon reception of a request for execution of a 

service module having an identifier, the runtime environment accesses the input class of a 
main module comprising the main program of the system, the main module installs an 
instance of a special class "Access Manager" of an API module that controls access to a 
service module and uses a method of this class for creating an instance of the input class of 

30 the requested service module, by means of a table associating the identifier with the index of 
the module in an array in which the module is referenced, the instance being returned by the 
method to the main program. 
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Other characteristics and advantages of the present invention will emerge more 
clearly v^ith the reading of the description below, written in reference to the attached 
drawings in which: 

- Fig. 1 schematically represents the various elements required for loading a portable 
object according to a first embodiment; 

- Fig. 2 schematically represents the various elements required for loading a portable 
object according to a second embodiment; 

- Fig. 3 represents the internal representation of a module; 

- Fig. 4a represents the conventional diagram of a smart card; 

- Fig. 4b represents the system required to constitute a virtual machine embedded in a 
smart card according to the prior art. 

- Fig. 4c represents the structure of the classes of an application. 

The method will be described in connection with Figs. 1 through 3, in a non-limiting 
way, in the case of the implementation of the invention in an embedded system, for example 
of the specific type constituted by a smart card or a similar portable object. The designation 
byte code or byte code program covers any intermediate pseudocode or program. 

The portable object constitutes, for example, a smart card and has a structure similar 
to the one described above in reference to Figs. 4a and 4b, and specifically comprises a 
RAM, ROM and EEPROM. The specific platform (60) and a conventional station (80) have, 
in ROM, a runtime environment (RE) comprising APIs (62) and an "on-platform" virtual 
machine (61). The specific platform (60) is represented in Fig. 1 as comprising the set of 
memories ROM and EEPROM. It should be noted that the specific platform (60) more 
specifically designates the runtime environment (RE) and the elements present in EEPROM. 
The portable object has, in ROM, an operating system <63). The APIs (62) present in ROM 
constitute the basic APIs of the API platform, loaded with the on-platform virtual machine 
for running the latter. 

The part (90) of the virtual machine outside the portable object comprises an 
intermediate pseudocode verifier (91), a converter (92) and possibly a signer (94). The signer 
delivers a signature for validating the passage through the verifier and the converter. This 
signature will be verified by the portable object at the time of loading. The loading into 
EEPROM of applications or new APIs for complementing the basic APIs is done by a loader, 
which can be composed of two parts, a part outside the portable object that can be installed in 
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the virtual machine outside the portable object (90), called a downloader (93), and a pait in 
the specific platform, called a loader (68). 

In a first embodiment, the specific platform (60) comprises two special modules, an 
API module (65) and a main module (66). The other modules are called service modules (67). 
5 Each module corresponds to a set of packages that will be stored in the same name space. The 
API platform designates the basic APIs (62) and all of the system classes that define the API 
module (65) or the module of the API platform. The main module comprises the main class 
defining the main program. Each module, except for the API module (65), has one particular 
class called "Entry Class," which constitutes the point of access to the module. For the main 

10 module, this "Entry Class" is the main class (CP), the one that contains a static method called 
"main." For the service modules, it is a class with only one constructor, without parameters 
and implementing a special public so-called "service" interface defined in the API platform. 
The loading of an application corresponds to the loading of a service module. Each module 
receives a specific identifier. Such an identifier, which is called MID, can for example be a 

15 number, a character string, or an array. For the sake of example, the idenfifier is a character 
string. 

When they are loaded into the platform by downloading mechanisms distinct from the 
virtual machine of the specific platform, the modules receive a number between 0 and n. 
Thus, based on this convention, n+1 modules at most can be present in the specific platform. 

20 During the loading of new service modules, the module downloader (93), along with the 

loader (68), maintains an array (TRM) (69) representing the modules. The number associated 
with a module is the index (DM) of this module in the array. The loader (68) also maintains a 
table (70) associating the index (IM) with the identifier (MID) of each module. The API 
module systematically receives, for the index IMq, the number 0, and the main module 

25 receives for the index IM] the number 1. The header of each module includes an indicator that 
allows the loader to determine the nature of the module - "main," "service," or "APT' 
module. 

The loader (68) can only load modules that are authorized to reside in the portable 
object, i.e., only modules having a signature recognized by the portable object. The loader 
30 (68) therefore includes means for verifying the signature of a received module, for comparing 
it to the signature recognized by the portable object, and in case of a negative comparison, for 
prohibiting the loading. 
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Conventionally, as defined in the prior art mentioned above, the source program (81) 
of an application is written, then compiled by a compiler (82), and then verified by the 
verifier (91). 

The static linking, performed in the converter (92) by a component of the converter 
5 called a linker, will resolve the symbolic references by assigning 

- a number (NCI) to each class of a module, 

- a number (NM) for each method in a class, and 

- a number (NA) for each attribute in a class. 

Each of these numbers (NCI, NM, NA) is between 0 and n, and can thus be 

10 represented by a byte. For example, each of these numbers is between 0 and 255 (n=255). 
The reference to a method or an attribute of a class will thus be coded into the linked 
pseudocode of the methods of the module in two bytes. The pseudocode will contain these 
two bytes, <NCI> for the class, and <NA> for an attribute or <NM> for a method. 

According to Fig. 3, the internal representation of an API module (65), a main module 

15 (66), or a service module (67) will contain an array (TRC) representing classes; the number 
(NCI) associated by the linker outside the embedded system with each class is the index (ICi) 
of the representation of this class in the array (TRC). Each class also has a reference to the 
index IMi of its module. Likewise, the representation of each class contains an array 
representing the methods (TRMe) and an array representing the attributes (TRA) belonging to 

20 the class. The number (NM) associated by the linker outside the embedded system with each 
method is the index IMi of the representation of this method in the array (TRMe), and the 
number (NA) associated by the linker outside the embedded system with each attribute is the 
index (lAi) of the representation of this attribute in the array (TRA). 

For example, we want a module to be able to refer only to its own classes and to the 

25 system classes of the API platform, the system classes corresponding to the classes of the 
"ClassPath" of a conventional platform. According to the invention, in order to make it 
possible to distinguish between a reference to a class internal to the module and the reference 
to a system class (or class external to the module), an internal (II) or external (IE) indicator is 
added to the reference to a method or an attribute. The resolved reference is then coded in 

30 three bytes: <IE/II> <NCI> <NM> or <IE/I> <NCI> <NA> 
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In accordance with an established convention, for the value n of the first byte <IE/II>, 
the value 255 in our example, corresponds to a reference <!!> internal to the module, and any 
other value for the first byte corresponds to a reference <IE> external to the module. 

The linker of the converter (92) of the virtual machine outside the portable object 
5 (90), first links the API module (65), which does not have any external references <IE> in its 
pseudocode , and produces a layout or arrangement corresponding to a scheme of symbolic 
names of its classes and their methods and attributes. During the linking of the other modules, 
this layout will be used to establish the external references to system classes of the API 
module (65), 

10 Based on our convention for the bytes encoding the references, there can be at most 

256 (n+1) classes in the API module and 256 classes in each additional module. 

During the execution of a service module, when the virtual machine (61) finds a 
reference to a method <NM> or an attribute <NA> in the pseudocode, knowing the class 
<NCI> in which this reference is found, it can directly retrieve the index <IMi> of the 

15 module in question, the latter corresponding to the external (IE) or internal (II) reference. 
Any external reference <IE> in the pseudocode of a service module will be systematically 
interpreted by the virtual machine as a reference to the API module. A service module or the 
main module cannot refer to the classes of any other module except those of the API module. 
The system classes of this API module cannot refer to the classes of a service module or the 

20 main module. The internal reference to a class of a module, corresponding to the value n for 
the first byte, does not require any knowledge a priori of the name space that will be assigned 
to the module. The fact that no fixed name space is defined a priori during the conversion 
phase makes it possible to accelerate the resolution of the references and to determine the 
naming space of a module during the loading, after the conversion phase. The virtual 

25 machine, during the interpretation of a reference to an attribute or a method in the 

pseudocode, uses the three cascaded indexes <IE/II> <NCI> <NM> or <IE/II> <NCI> 
<NA>. The memory space of the module being determined, the index <NCI> determines the 
desired entry into the array (TRM) of the classes of the module, then the last index <NM> or 
<NA> gives the desired entry into the method array (TRMe) or the attribute array (TRA). 

30 The API module comprises a special class (64), called class ''Access Manager", which 

comprises a native method (getServicelnstance) whose role is to return an object that is an 
instance of the input class of the requested service module, from the identifier (MID) of the 
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module. This method uses the MID/IMi association table (70) to find the index of the 
requested module in the module array (69), then creates an instance of the input class of this 
module, an instance that is returned by the method. According to the invention, the class 
"Access Manager" (64) is protected by construction by a method that consists of prohibiting 
5 this class from having more than one instance. This method (getServicelnstance) belongs to 
the main program contained in the main module. The main module, which is activated first 
when the portable object is used, creates one and only one instance of the class "Access 
Manager", which allows it to use the method getServicelnstance, but bars any other service 
from creating another instance for using this method. 

10 In operation, just like in a conventional platform, the runtime environment (RE) 

accesses the input class (EC) of the main module and activates its input method (main). The 
main module, being the first one activated, installs an instance of the class "Access Manager" 
before any other service does so, since in order to activate other services, the main module 
must already have such an instance of the access class. 

15 This simple device makes it possible to reproduce the protective effect linked to the 

concept of a naming space in a conventional platform. The simple fact that a service module 
is loaded into the module array, and that the presence in the pseudocode of any external 
references is interpreted by the virtual machine as a reference to the API module, renders this 
module completely inaccessible directly by the other modules, thus creating a total firewall. 

20 This first embodiment makes it possible to obtain the advantages of a firewall 

produced by name space separation in the context of a two-part virtual machine. However, 
this embodiment is not very flexible, and has two drawbacks. 

First, it prevents any modification or extension of the system classes with modules 
that are already pre-linked. A conventional Java architecture makes it possible to modify and 

25 extend the classes of the API platform without having an impact on the already compiled 
classes of additional modules. But in the embodiment described above, any modification of 
the system classes, although invisible for alien modules, would modify the layout of the API 
platform and would make it necessary to modify the pre-linked pseudocode of each module 
already linked with a prior version of the layout, and consequently the interpreter. 

30 Secondly, the pre-linked modules are assumed to be portable between the various 

embedded platforms or terminals, which requires each of these platforms to have the same 
layout as the API platform, thus prohibiting the utilization of any proprietary extension. 
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In order to partially remedy these drawbacks, a variant of the first embodiment 
consists of requiring that, in the numbering of the layout, the public classes come first, before 
the classes in private packets. In addition, the public methods or public attributes come before 
those that are protected and those that are in private packages and in private classes. This 
5 makes it possible to freely add new public classes into the API module (API). 

Fig. 2 represents a second embodiment that allows upgrading of the API platform. 
The API platform is constituted by several API modules (100) that can be loaded separately, 
instead of being constituted by a single API module. 

In this embodiment, the downloader (93) and the virtual machine share two module 
10 arrays and two MID/index association tables instead of one of each, an array (101) and an 

association table (102) for the API modules and an array (103) and an association table (104) 
for the non-API modules corresponding to the service module (67) and the main module (66). 

Each module has in its header an indicator indicating its nature, "Service" or "API", 
which allows the loader to load the module into the API module array (101) or into the non- 
15 API module array (103). This indicator is placed in the header of the module during the 
compilation phase by the converter. 

The firewall constituted by the separation of the name space is present only between 
the non-API modules. Any external reference to a service module will be interpreted by the 
interpreter of the on-platform virtual machine as an index of the API module array. 
20 The non-API modules are numbered from 0 to 255 at most, in the example in which 

n=255. For example, 0 is the index of the main module (66). The API modules (100) are 
numbered from 0 to 254 at most, 0 being for example the index of a so-called primary API 
module, which contains all of the native methods. According to the convention described 
above, this allows at most 255 (n) different modules in the API platform. The reference to a 
25 method or attribute in the pseudocode is: 

«IE/II> <NCI> <NM/NA» 

The value 255 (n)for the first byte indicates, as in the first embodiment, a reference 
internal to the module. Each value different from 255 indicates a reference external to a 
specific module (100) of the API module array of the API platform. 
30 After the performance of the linking by the off-platform linker (92), the pseudocode 

of a module includes a header having an array of referenced modules used to link the current 
module. This referenced module array comprises at most 255 entries, each entry 
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corresponding to the identifier (MID) of an API module (100). The first byte of an external 
reference in the pseudocode will therefore be an index in this array. When a non-API module 
(67, 66) is loaded into the platform, the index numbers associated with API modules (100) 
are known, and thus each first byte of an external reference is replaced by the index number 
5 associated with the referenced API module using the MID/IMi association table (102) of the 
API modules (100). This replacement is the only linking operation performed in the specific 
platform by the loader (68), the MID/IMi association table (102) being used only for 
performing this linking operation. 

For the sake of example, let's assume that in the pseudocode of a service module 

10 "TEST", we have the reference to a method number 5 of class number 7 of an API module 
whose identifier (MID) is 'TOO". Let's also assume that "FOO" is the identifier of the fourth 
external API module found referenced in the service module "TEST". The reference in the 
pseudocode is therefore constituted by the following three values: 3, 7, 5. 

The number 3 corresponds to the fourth index in the array of referenced modules 

15 present in the header of the module, which comes at the beginning of the pseudocode, the 
value of this entry being the identifier (MID) "FOO". Let's assume that at the time the API 
module "FOO" is loaded, the internal index 34 has been assigned to it in the target platform, in 
the association table (102) of the API modules. Therefore, the loader (68), using the 
association table (102), modifies the reference in the pseudocode of the service module 

20 "TEST" so that it becomes: 34, 7, 5. 

During the execution of the pseudocode of a module, a reference external to the 
module is systematically interpreted by the virtual machine as an entry in the API module 
array. The modules of the non-API module array remain invisible to one another as well as to 
the other API modules. This simple device makes it possible to reproduce the protective 

25 effect linked to the concept of a naming space in a conventional platform. The simple fact 
that a module is loaded into the non-API module array makes it completely inaccessible 
directly by the other modules, thus creating a total firewall. 

The API module array (101) comprises a specific module (105), called an "API 
Access" module, which comprises a native method (getServicelnstance) in a class "Access 

30 Manager" whose role is to return an object that is an instance of the input class of the 

requested service module. This method uses the MID/IMi association table (104) to find the 
index of the requested service module in the non-API module array (103), then creates an 
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instance of the input class of this module, which is returned by the method to the main 
program. The recommended security policy is to make the class "Access Manager" a 
protected class whose constructor and methods are declared protected. In addition, the "API 
Access" module (105) includes a protection consisting of prohibiting the class "Access 
5 Manager" from having more than one instance. This method is reserved for the main program 
contained in the main module (66). The main module, which is activated first, creates an 
instance of the module Access Manager, which allows it to use the method 
getServicelnstance, but prohibits any other service from creating another instance for using 
this method. Thus, the main module can create service instances. 

10 Several methods can be used to obtain this protection, which consists of prohibiting 

the class "Access Manager" from having more than one instance. The constructor of the class 
"Access Manager" can, for example, inhibit the request for creating an instance when one 
already exists and trigger a security exception. In operation, the runtime environment (RE) 
accesses the input class of the main module (66) and activates its input method (main). The 

15 main module, being the first one activated, installs an instance of the class "Access Manager" 
of the Access module before any other service does so. 

In order to allow a service module to activate another service module, this strict 
security policy can be modified by adding to the class "Access Manager" of the API Access 
module (105) public classes that will allow any module to send requests to it. These requests 

20 will be processed and controlled by the sole instance created by the main module. These 
public classes specifically include a static method that makes it possible to obtain the sole 
instance. A module having access to the object that is the instance of the class "Access 
Manager" can activate another service module and use it, but it cannot directly reference its 
classes, its methods or its attributes without being referred by the virtual machine, given that 

25 any external reference in the pseudocode is a reference internal to the module or a reference 
external to an API module. 

For a simple embodiment of this solution, it is necessary not to have circular 
references among the API modules. Consequently, the transitive closure of the relation 
"refers to" must be a strict partial order on a set of modules. It is thus possible to design, in 

30 the linker of the converter (92), a simple strategy for linking and producing the layout of the 
API modules by first processing the minimum elements not yet linked. It is possible to use 
the same strategy based on a partial order for downloading the API modules, so that when a 
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module M is downloaded, all of the modules to which it refers have already been 
downloaded, and a number has been assigned to them. The assignment of the internal index 
in the target platform is done by the module loader (68) by assigning the index n-1 to the API 
of order n. An API module cannot refer to another API module with a higher index. 
5 The utihzation of this system of dual module arrays (101, 103) and association tables 

(102, 104) makes it easy to replace a single API module with several API modules that can be 
loaded separately. The replacement of a single API module with several API modules makes 
it possible to extend the API platform with new modules, without modifying the linking of 
the modules already loaded, and without changing the security provided by the firewalls. Of 

10 course, these two embodiments are not compatible; the modules must be pre-linked 
specifically for one embodiment or the other, the pseudocode related to one of the 
embodiments not being portable to a platform implementing the other embodiment. 
Moreover, the interpreter of the virtual machine differs form one embodiment to the other. In 
the first embodiment, the virtual machine manipulates only one array and one association 

15 table; the first byte of a reference is interpreted by the virtual machine as an internal reference 
for any value equal to n, and as an external reference to the sole API module for any value 
different from n. In the second embodiment, the virtual machine manipulates two arrays and 
two association tables: the first byte of a reference in the pseudocode is interpreted by the 
virtual machine as a reference internal to the module for any value equal to n, and any value 

20 different from n will be taken directly as an index in the API module array. In both 

embodiments, the interpreter of the virtual machine comprises means for comparing the first 
byte of the three coding bytes of a reference to a method or an attribute with a given value n 
in order to decide whether it refers to a class that is internal or external to the module. The 
numbering of the API modules can be determined at the time of loading, in order to 

25 permanently set the external references in the pseudocode in a very simple way. 

The same mechanisms are used to handle both types of modules, although the way in 
which they are used and the security obtained are entirely different. Any module can freely 
access the API modules, since their classes are system classes. The utilization of the modular 
approach is used with the service modules to obtain a strong firewall for protecting these 

30 modules from any direct access. 
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The method according to the invention can be implemented in any type of portable 
object having limited resources, such as for example 16 Kb of ROM, 8 Kb of EEPROM and 
256 k of RAM. 

Other modifications within the capability of one skilled in the art are also part of the 
spirit of the invention. 
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CLAIMS 



1 1 . Method for loading applications into an embedded system comprising a 

2 runtime environment including a virtual machine comprising an intermediate pseudocode 

3 language interpreter and application programming interfaces (API), from a station on which 

4 the source code of the application is written, compiled into pseudocode by a compiler (82) , 

5 verified by a verifier (91), converted by a converter (92) and loaded by a loader (93, 68), is 

6 characterized in that: 

7 - the conversion comprises the performance of the static linking of a plurality of sets 

8 of packages to be stored in the same name space in the embedded system, called modules, by 

9 assigning an identifier to each module (MID), and a reference number to each class (NCI), 

10 each method (NM) and each attribute (NA) encapsulated in the classes of the module, 

11 - the reference to a method or an attribute in the linked pseudocode of a module,, 

12 being coded in three bytes constituted by an indicator indicating the reference to a class 

13 internal (II) or external (IE) to the module, the number of the class (NCI), and either the 

14 number of the method (NM) or the number of the attribute (NA), 

15 - the modules loaded are one or more application program interface modules 

16 comprising system classes or service modules, each corresponding to an application, a 

17 reference (IE) to an external class being systematically interpreted by the virtual machine as a 

18 reference to an application program interface module. 

1 2. Method for loading applications into an embedded system according to claim 

2 1 , characterized in that the loading of the modules into the embedded system comprises the 

3 storage of at least one array (69, 101, 103) representing the modules, the number (IMi) 

4 between 0 and n associated by the linker with a module constituting the index of said module 

5 in the array, and a table (70, 102, 104) storing the association of the index in the array 

6 representing the identifier (MID) of said module, said array and the table being in 

7 programmable nonvolatile memory, an external reference (IE) to an external module in the 

8 pseudocode being interpreted by the interpreter of the virtual machine as constituting an 

9 index for access to the module equivalent to the one in the module array. 
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1 3. Method for loading applications into an embedded system according to claim 

2 2, characterized in that the loading comprises the storage, for each module, of an array (TRC) 

3 representing its classes, comprising a reference to the index of its module and, for each class, 

4 an array representing attributes (TRA) and methods (TRMe). 



1 4. Method for loading applications into an embedded system according to claim 

2 2, characterized in that the modules are referenced in a single module array, the system 

3 classes are different from n will be interpreted by the virtual machine as a reference to said 

4 API module. 



1 5. Method for loading applications into an embedded system according to claim 

2 4, characterized in that the classes being declared public, or in private packages, the 

3 attributes and methods being declared protected, in private packages or in private classes, the 

4 numbering of the classes is done in order of the public classes foUov^ed by the classes in 

5 private packages; the numbering of the attributes or methods is done by the converter (92) in 

6 order of the attributes or methods that are public, protected in private packages, and in private 

7 classes. 



1 6, Method for loading applications into an embedded system according to claim 

2 2, characterized in that the system classes are contained in several API modules that can be 

3 loaded separately, the loader (68) maintains in the programmable nonvolatile memory tv^o 

4 arrays representing modules and two corresponding MID/IMi association tables, one for the 

5 API modules and the other for the non-API modules, the loader loading the modules into one 

6 of the two arrays based on the nature of the module specified in its header, any external 

7 reference of a module of the module array being interpreted as a reference to the index of the 

8 API module. 



1 7. Method for loading applications into an embedded system according to claim 

2 6, characterized in that static linking of a module is performed in such a way that the 

3 reference to a class external to a non-API module in the intermediate pseudocode is an index 

4 in an array of the header of the module, wherein each entry is an identifier (MID) of a 

5 referenced API module, the loading of said module into the target platfonn comprising the 
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6 replacement of said reference with the number of the index of the API module obtained from 

7 the identifier (MID) in the MED/IMi association tables of the API modules. 

1 8. Embedded system comprising a virtual machine and an API platform 

2 including application program interfaces, a fixed nonvolatile memory, a programmable or 

3 modifiable nonvolatile memory, and a random access memory, is characterized in that the 

4 programmable nonvolatile memory comprises at least one API module comprising system 

5 classes and service modules, at least one array representing modules (TRM), in which the 

6 modules are indexed, and a table (70, 104) associating the index (IM) of a module in the 

7 representing array with the identifier (MID) of said module, each module comprising an array 

8 for representing classes (TRC), in which the classes are indexed and in which each class has a 

9 reference to the index (IM) of its module, each class comprising an array for representing 

10 attributes (TRA) and methods (TRMe), in which the attributes and methods are indexed, the 

1 1 reference to a method or an attribute being coded in at least three bytes corresponding to a 

12 reference to a class internal (II) or external (DE) to the module, a reference external to the 

13 module constituting the index of the API module in the module array, a class number (NCI) 

14 corresponding to the index of the class in the table representing the classes of the module, and 

15 a method (NM) or attribute (NA) number corresponding to the index or the method or the 

16 attribute in the array representing the methods or attributes of the class of the module. 

1 9. Embedded system according to claim 8, characterized in that it includes means 

2 for comparing the first byte of the three bytes encoding a reference to a method or an attribute 

3 to a given value n in order to decide whether it is an internal or an external class. 

1 10. Embedded system according to claim 8, characterized in that it comprises a 

2 main module comprising the main program of the system. 

1 11. Embedded system according to claim 8, characterized in that it the classes are 

2 indexed in order of the public classes followed by the classes in private packages, and the 

3 attributes and methods are indexed in the order of the attributes or methods that are public, 

4 protected, in private packages, and in private classes. 
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1 12. Embedded system according to claim 11, characterized in that the 

2 programmable nonvolatile memory comprises several API modules comprising system 

3 classes, two arrays (101, 103) representing modules, one for the API modules and the other 

4 for the non-API modules and the main module, and two MID/EMi association tables (102, 

5 104), each corresponding to an array representing modules. 

1 13. Embedded system according to claim 10, characterized in that it comprises an 

2 access manager class "Access Manager" of an API module (105) comprising a method that 

3 makes it possible to create an instance of a service module, via the main module, said class 

4 having a protection that prohibits it from having more than one instance. 

1 14. Method for executing an application of a multi-application embedded system, 

2 comprising a runtime environment including a virtual machine comprising an intermediate 

3 pseudocode language interpreter and application programming interfaces (API), is 

4 characterized in that during the execution of the intermediate pseudocode of a service 

5 module, corresponding to an application, referenced in a module array, the reference to a 

6 method or an attribute in the pseudocode, coded in at least three bytes corresponding to a 

7 reference to a class internal (II) or external (IE) to the module, a class number (NCI) and a 

8 method (NM) or attribute (NA) number, a reference external to the module is interpreted by 

9 the virtual machine as a reference to the index of an API module in the array of the API 
10 module or modules. 

1 15. Method for executing an application of a multi-application embedded system 

2 according to claim 14, characterized in that, upon reception of a request for execution of a 

3 service module having an identifier (MID), the runtime environment accesses the input class 

4 of a main module comprising the main program of the system, the main module installs an 

5 instance of a special class "Access Manager" of an API module that controls access to a 

6 service module and uses a method of this class for creating an instance of the input class of 

7 the requested service module, by means of a table associating the identifier with the index of 

8 the module in an array in which the module is referenced, the instance being returned by the 

9 method to the main program. 
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ABSTRACT 



METHOD FOR LOADING APPLICATIONS IN A MULTIAPPLICATION 
ONPLATFORM SYSTEM EQUIPPED WITH DATA PROCESSING RESOURCES, 
CORRESPONDING EXECUTING SYSTEM AND METHOD 



The present invention relates to a method for loading applications into a multi- 
application embedded system, the corresponding embedded system, and the method for 
executing an application of the embedded system. The method for loading applications into 
an embedded system comprising a runtime environment including a virtual machine 
comprising an intermediate pseudocode language interpreter and application programming 
interfaces (API), from a station on which the source code of the application is written, 
compiled into pseudocode, verified and converted, is characterized in that the conversion 
comprises the performance of the static linking of a plurality of sets of packages to be stored 
in the same name space in the embedded system, called modules, and constituting an 
application program interface module or a service module corresponding to an application, 
and consists of assigning an identifier to each module (MID) and a reference number to each 
class (NCI), each method (NM) and each attribute (NA). The reference to a method or an 
attribute in the linked pseudocode of a module is coded in three bytes constituted by an 
indicator indicating the reference to a class internal (II) or external (IE) to the module, the 
number of the class (NCI), and either the number of the method (NM) or the number of the 
attribute (NA), a reference (IE) to an external class being systematically interpreted by the 
virtual machine as a reference to an application program interface module. 
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Declaration and Power of Attorney for Patent Application 
Declaration et Pouvoirs pour Demande de Brevet 



French Language Declaration 



En tantque Tinventeur nomme ci-apres^ je declare par le present 
acre que: 



^pn domicile, mon adresse postale ec ma nationalite sont cenx 
Sgnrant ci-dessous k cote de mon nom. 



5|' crois etre le premier inventeur original et unique (si un seul 
ig)m est mentionne ci-dessous), ou Fun des premiers co- 
fSventeurs originaux (si plusieurs noms sont mentionnes ci- 
^ssous) de Tobjet revendique, pour iequei une demande de 

s^steme embarque multi-application muni de 
rijssources de traitement de donnees, sy steme 
^barque correspondant, et procede 
tf^xecution d'une appl ication d'un syste me 
eSllbarque correspondant. 

et dont la description est foumie ci-joint a mo ins que la case 
suivante n'ait ete cochee: 

□ a ete deposee le . 



sous le numero de demande des Etats-Unis ou le 
numero de demande intemationai PCT 

et modifiee le 

(le cas echeant). 



Je declare par le present acte avoir passe en revue et compris le 
contenu de la description ci-dessus, revendications comprises, 
teiles que modifiees par toute modification dont il aura ete fait 
reference ci-dessus. 



Je reconnais devoir divuiguer toute information pertinente a la 
brevetabilite, comme defmi dans le Titre 37. § L56 du Code 
federal des reglementations. 



As a below named inventor, I hereby declare that: 



My residence, post office address and citizenship are as stated 
next to my name. 



I believe I am the original, first and sole inventor (if only one 
name is listed below) or an original, first and joint inventor (if 
plural names are listed below) of the subject matter which is 
claimed and for which a patent is sought on the invention entitled 



the specification of which is attached hereto unless the following 
box is checked: 

□ was filed on 

as United States Application Number or PCT 
Intemationai Application Number 

and was amended on 

(if applicable). 



I hereby state that I have reviewed and understand the contents 
of the above identified specification, including the claims, as 
amended by any amendment referred to above. 



I acknowledge the duty to disclose information which is material 
to patentability as defined in Title 37, Code of Federal 
Regulations, § 1.56. 
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French Language Declaration 

Je revendique par le present acte avoir la priorite etrangere, en 
verm du Titre 35, § 1 19(a)-(d) ou § 365(b) du Code des Etacs- 
Unis, sur toute demande etrangere de brevet ou certificat 
d*inventeur ou, en verm du Titre 35, § 365(a) du meme Code, sur 
toute demande Internationale PCT designant au moins un pays 
autre que les Etats-Unis et figurant ci-dessous et, en cochant la 
case, j'ai aussi indique ci-dessous toute demande etrangere de 
brevet, tout certificat d'inventeur ou toute demande intemationaie 
PCT ayant une date de depot precedant ceile de la demande a 
propos de laquelie une priorite est revendiquee. 



Prior foreign application(s) 
]^en^j^^s) de brevet anterieure(s) 



FR 



(Number) 
(Numero) 



(Country) 
(Pays) 



^Number) 
fSfumero) 



(Country) 
(Pays) 



}^;revendique par le present acte tout benefice, en verm du Titre 
§ 1 19(e) du Code des Etats-Unis, de toute demande de brevet 
gifovisoire effectuee aux Etats-Unis et figurant ci-dessous. 



^ipiication No.) 
^ de demande) 

@bpiication No.) 
(^ de demande) 



(Filing Date) 
CDate de depot) 

(Filing Date) 
ODate de depdt) 



Ml^vendiqne par ie present acte tout benefice, en verm du litre 
33j § 120 du Code des Etats-Unis, de toute demande de brevet 
egecmee aux Etats-Unis^ ou'en vertu du Titre 35, § 365(c) du 
r@me Code, de toute demande Internationale PCT designant les 
SSts-Unis et figurant ci-dessous et, dans la mesure oii I'objet de 
chacune des revendications de cette demande de brevet n'est pas 
divulgue dans la demande ancerieure americaine ou intemationaie 
PCT, en verm des dispositions du premier paragraphe du Titre 
35, § 112 du Code des Etats-Unis, je reconnais devoir divulguer 
toute information pertinente a la brevetabilite, comme defini dans 
le Titre 37, § U6 du Code federal des reglementations, dont j'ai 
pu disposer entre la date de depot de la demande anterieure et la 
date de depot de la demande nationale ou intemationaie PCT de 

^'|?6t/fIWI3 17/11/00 



(Application No.) 
(N^ de demande) 

(Aoplication No.) 
(N" de demande) 



(Filing Date) 
CDate de depCt) 

(Filing Date) 
(Date de depot) 



Je declare par le present acte que toute declaration ci-inciuse est, 
a ma connaissance, veridique et que toute declaration formuiee 
a partir de renseignements ou de suppositions est tenue pour 
veridique; et de plus, que toutes ces declarations ont ete 
formulees en sachant que toute fausse declaration volontaire ou 
son equivalent est passible d'une amende ou d'une incarceration, 
ou des deux, en verm de la Section 100 1 du Titre 1 8 du Code des 
Etats-Unis, et que de telles declarations volontairement fausses 
risquentde compromettre la validite de la demande de brevet ou 
du brevet delivre k partir de celle-ci. 



I hereby claim foreign priority under Title 35, United States 
Code, § I I9(a)-(d) or § 365 (b) of any foreign application(s) for 
patent or inventor's certificate, or § 365(a) of any PCT 
International application which designated at least one country 
other than the United States, listed below, and have also 
identified below, by checldng the box, any foreign application for 
patent or inventor's certificate, or PCT International application 
having a filing date before diat of the application on which 
priority is claimed. 



17/11/99 



Priority Claimed 
Droit de priorite revendique 



(Day/Month/Year Filed) 
(Jour/Mois/Annee de depdt) 

□ 

(Day/Month/Year Filed) 
(Jour/Mois/Annee de depot) 

I hereby claim the benefit under Title 35, United States Code, § 
1 19(e) of any United States provisional application(s) listed 
below. 



I hereby claim the benefit under Title 35. United States Code, § 
120 of any United States application(s), or § 365(c) of any PCT 
International application designating the United States, listed 
below and, insofar as the subject matter of each of the claims of 
this ^plication is not disclosed in the prior United States or PCT 
International application in the manner provided by the first 
paragraph of Title 35, United States Code, § 112, 1 acknowledge 
die duty to disclose informatioji which is material to patentability 
as defined in Title 37, Code of Federal Regulations, § 1.56 which 
became available between the filing date of the prior application 
and the national or PCTT fiitemational filing date of this 
application. 



PENDING 

(S tarns) (patented, pending, abandoned) 
(Statut) (brevete, en cours d'examen, abandonne) 

(Stams) (patented, pending, abandoned) 
(Statut) (brevete, en cours d'examen, abandonne) 

I hereby declare that all statements made herein of my own 
knowledge cu-e true and that all statements made on information 
and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false 
statements and the like so made are purushable by fine or 
imprisonment, or both, under Section 1001 of Tide 18 of the 
United States Code and that such willful false statements may 
jeopardize the validity of the application or any patent issued 
diereon. 
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French Language Declaration 

IpOUVOIRS: En tant que Tinventeur cite, je designe par la 
presence l'(les) avoca£(s) et/ou agentfs) suivant(s) pour qu'ils 
poursuive(nt) la procedure de cette demande de brevet et 
traite(nt) toute affaire s'y rapportant avec TOffice des brevets et 
des marques: ( mentionner le nom et le numero 
d'enregistrement). 



Adresser toute correspondance a: 



POWER OF ATTORiVEY: As a named inventor. I hereby 
appoint the following attomey(s) and/or agent(s) to prosecute this 
application and transact ail business in the Patent and Trademark 
Office connected there^^vith: (list name and registration number) 

Edward J, Kondracki, Reg. No .^^^Z^LiQ^ 
Dennis P. Clarke, Reg. No ._22-,-S-^^ 
Wiiliaia L. Feeney, Rag. No ,^2.^.344 

John C. Kerinc;. R?>g. Mn./^2,^21 



Send Correspondence to: 
Miles Sc Scockbridge P.O. 

1751 Pinnacle Drive, Suite 500 



Adresser tout appel telephonique a: 
(nom et numero de telephone) 



r Q q o n 



Direct ieiephoneXTaHs to:' 
( name and telephone number) 

7n--qm-Qnnn 



f flESeJi^ ^•jjggg^u premier inveaceur ^ 


Full name of sola or first inventor 


f Signature de rinventeur CJ^C^i^^^^^ ^^^^ /a1/V^^^ 


Inventor^s signature Date 


tn 8 alley difWSil 

^©omicile 78340 LES CLAYES SOUS BOIS - FRANC 


EResidence 




Citizenship 


^Adresse postal^ gn^^ iyiaj| 


Post Office Address 


/»34U Lby CLAYbS ^UUS BUIS - hKANC 




Non^^rji^^jj^ij^j|p^n^g[jjjnvente le cas echeant 


Full name of second joint inventor, if any 


Signature du second inventeur ,/4i-4— ^^^^ ^1 


Second Inventor's signature ^ 


^ Date 


96 Uranus terrac^ 
Domicile ^4 g^j^ FR ANCISCO - ETATS-UNU 


J Residence 




Nationalite Fr^Tigaise 


Citizenship 


Adresse postaiS6 Uranus terrace 

CA 941 14 SAN FRANCISCO - ETATS-UNI^ 


Post Office Address 







(Foumir les memes renseignements et la signamre de tout co* (Supply similar information and signature for third and 

inventeur supple mentaire,) subsequent joint inventors.) 
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